Improving the Development System Model

My impression is that successful projects belong to the same people, the kind of people who recognize problems and deploy countermeasures more effectively than others. In order to be successful at what they develop, these people apply far more than a single model not only to detect problems and identify countermeasures, but to plan. One of these models—a model that we all employ, consciously or not—I’ve called the development system. Let me give you an example. I had the opportunity of working on the BSY-2 combat system for the SeaWolf submarine. This system consisted of millions of lines of code and thousands of interfaces, and it required that we provide and maintain rather large documents to describe it. I worked in the tools group that kept several of the design specifications in relational databases. Code and design elements were re-used, resulting in a huge number of many-to-many relationships in the system's design specifications. A single change would impact many elements, from several sources. Manually grubbing though the interface specs (dozens of feet thick and housed by multiple contractors at multiple locations) would have been too slow and prone to error. Keeping the specs in relational databases allowed us to automate traceability and find change impacts with a query. It was the bill of materials system from hell. When the new development workstation network went in we were using a mainframe-class machine at the time and all that publishing was supposed to happen on the workstations, I predicted it wouldn’t work. The first run of the smallest of the hundreds of deliverable specs took over a week before it crashed. It never worked on that platform, although that platform, and those tools on that platform were successfully used for other development projects before and since. In this case why was it that, as my old boss used to say, a process that works successfully for one hundred changes may collapse under ten thousand changes? When we ask questions about what went wrong—excluding questions about the particulars of the system we’re building—we’re asking questions about a model called the development system. We’re asking questions and we’re making observations about the personnel, tools and procedures used to develop a software system. The BSY-2 system presented many unique challenges to the development system used to build it.